• Closes

Additional details

This is a DRAFT proposal

In order to verify performance improvements, this adds a "stress test" e2e test to the driver that simulates interacting with extremely large virtual scrolling lists. This test should probably not be run with "legacy" visibility, as it immediately causes the browser to eat up all available memory and crash. This fixture works perfectly fine outside of Cypress.

This introduces an experimentalFastVisibility option, that switches our visibility detections to an alternative algorithm. This algorithm has some caveats, but it is much faster than the current visibility algorithm.

Cypress uses this visibility algorithm not just for visibility assertions, but also for every interaction that requires "interactability." It's memory intensive and can cause unnecessary layout thrashing due to repeated access of CSS properties that require layout recaulcation.

The "fast" visibility algorithm:

1. Assumes body and html are always visible; this is in line with current visibility behavior
2. Uses the built-in checkVisibility method as first pass, with all options enabled. The following states are considered hidden by this method:

• The element does not have an associated box
• The element is not being rendered because it or one of its ancestors has set content-visibility to `hidden
• It has an opacity of 0
• The value of its visibility property makes it invisible
• content-visibility CSS value is auto, and its derived value prevents the element from being rendered

3. If the element is an <option> or <optgroup>, it defers to the visibility of the parent <select> element. If there is no parent <select> element (an invalid DOM tree state), the element is considered hidden.
4. If the element is still considered visible, it performs a more comprehensive check with an adaptive point sampling algorithm

The point sampling algorithm:

1. Implements a visibleAtPoint check, which uses document.elementFromPoint to determine which element is at the top of the render context at that point. If the element at that point is the subject element or a child of the subject element, the subject element is considered visible at that point.
2. From the bounding rectangle of the subject element, it checks the four corners and center. If any of these points are visible, the subject element is considered visible.
3. If none of these points are visible, it divides the bounding rectangle in to four sub-rectangles, and performs the same sampling on them.
4. The sampling algorithm returns true if any part of the element is visible, but for performance constraints it will only subdivide to a limited depth, and will stop subdividing if the sampling rectangles fall below 1px in both dimensions.

Benefits over the legacy algorithm:

• Constant-time in the best case, and bounded exponential in the worst case (point sampling on a fully hidden element)
• Detects when an element is fully covered by positioned elements outside its ancestor tree
• Can be tweaked to provide access to threshold-based visibility
• Could be extended to require a minimum visible size for an element to be considered actionable tap events, to test conformation with UX guidelines regarding the size of touch targets
• Does not crash when running the virtual scroll stress tests

Caveats:

• Elements that are outside the bounds of the browser viewport will always be considered hidden with this algorithm
• Elements with pointer-events:none either explicit or inherited will always be considered hidden
• <option> elements that are not a direct child of <select> or <optgroup> elements are not considered visible
• <optgroup> elements that are not a direct child of <select> or <optgroup> elements are not considered visible
• Certain other edge cases that are considered hidden to this algorithm may be visible to the user, especially when it comes to elements that have a 0 height or width and have visible children. In these cases, it may be better to assert visibility on the visible children rather than the containing element.
• Shadow dom support is unknown at this time
• Some of the current visibility.cy.ts tests fail because the subject element is either off-screen, or covered by an absolute/fixed element that is not an ancestor.
• If even 1px of the subject element is visible, it will be considered visible. Potential consideration: configurable threshold?

Future performance improvements:

• Memoize elementFromPoint calls
• delete old records from memoization maps to reduce memory footprint
• Use requestAnimationFrame to measure the BoundingClientRect of the subject element; this is difficult due to how the visibility & interactability checks are currently wired through jquery selectors, which prevents this method from being async

Steps to test

How has the user experience changed?

PR Tasks

• Have tests been added/updated?
• Has a PR for user-facing changes been opened in cypress-documentation?
• Have API changes been updated in the type definitions?